Internet Info 1994 March

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-ietf-sip-overview-00.txt < prev next >

Wrap

Text File | 1993-10-06 | 45.8 KB | 1,238 lines

S. Deering (Xerox PARC) P. Francis (Bellcore) R. Govindan (Bellcore) October 1993 Simple Internet Protocol Plus (SIPP): Overview of Routing and Addressing Extensions to SIP Status of the Memo: This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." Please check the I-D abstract listing contained in each Internet Draft directory to learn the current status of this or any other Internet Draft. 1. INTRODUCTION The Simple Internet Protocol Plus (SIPP) retains most of the simpli- city of SIP [1], while adding some of the features provided by Pip [2]. Specifically, SIPP uses the same syntax as SIP, but the use of the SIP Routing Header (an option similar to the loose source route option of IP) has been enhanced to enable the features provided by the Pip FTIF Chain style of routing. This document primarily describes the additions to SIP that enable provider selection, mobility, auto-configuration, and variable-length addressing. Thus, this document targets those people who already understand SIP, and wish to understand what additional features come with SIPP. A future document will provide a complete description of SIPP routing and addressing. The authors would like to acknowledge the contributions of Bob Gilli- gan (Sun), Bob Hinden (Sun), Christian Huitema (INRIA), and Erik Nordmark (Sun). 1.1. Terminology The terminology defined in the SIPP Specification [8] applies to this document. The first three terms below are copied from [8] for clar- ity. The following additional terminology is defined below that: address: A 64-bit SIPP layer identifier for a node or set of nodes. An address can be used for both routing and identification purposes. uniqueness scope: The topologically defined region over which an address may be assigned to no more than one node or set of nodes. routing scope: The topologically defined region over which hosts and routers have sufficient routing information to forward SIP WG, Expires April 1, 1994 [Page 1] draft-ietf-sip-overview-00.txt October 1993 a packet toward the node(s) identified by that address. route sequence: The sequence of addresses consisting of the source address, the destination address, and the addresses encoded in the optional Routing Header of the SIPP packet. address sequence: A sequence of addresses that forms part of the route sequence. The address sequence is used for the purpose of routing to a node in the case where a single (64-bit) address has insufficient routing scope. identifying address: The low-order address in an address sequence. Of the addresses in an address sequence, only the identifying address is used to identify the source and destination of a packet (for instance, by the transport protocol). 2. SIPP ADDRESSING A SIPP address serves two purposes. One is to uniquely identify the node (or set of nodes) to which the address belongs. The other is to specify the location of the addressed node(s) in the internet topol- ogy, to facilitate routing. SIPP addresses are unlike IP addresses (and similar to OSI NSAP [9] addresses) in that they identify nodes (i.e., hosts or routers) rather than interfaces. This having been said, it is possible to assign SIPP address prefixes on a per-interface basis, with the result that packets to a node will tend to arrive over the interface from which the node's address was derived. A SIPP address is said to have a certain "routing scope", which is the topological region over which nodes have sufficient routing information to deliver a packet to the node(s) identified by that address. Most SIPP addresses have global routing scope, meaning they are routable from anywhere in the internet. However, some addresses have less than global routing scope. For example, during bootstrap- ping a SIPP node may use an address derived from its link-level address (e.g., an Ethernet address) that is only locally routable. Every SIPP packet contains two Identifying Addresses (IADs), identi- fying the source and destination nodes of the packet. The transport-layer pseudo-header checksum for the packet is calculated using the two IADs. The two IADs may or may not contain sufficient location information to route the packet to its destination(s) (or to route an error SIP WG, Expires April 1, 1994 [Page 2] draft-ietf-sip-overview-00.txt October 1993 message back to its source). When they are insufficient, an optional SIPP Routing Header is included in the packet to carry the additional addressing information required for routing. These additional addresses may be viewed as high-order extensions of the IADs. The additional addresses and the IAD, taken together, are called an address sequence. For instance, an address sequence can be used for a mobile node that is attached to a place in the internet other than the location speci- fied by its IAD. Or, an address sequence can be used if the routing scope of the IAD is not sufficient (as may happen if the internet grows too large to assign globally-routable addresses to all nodes). This way, the address sequence can be used to achieve the effect of a variable length address. Even when the address sequence is used to extend the address length beyond 64 bits, however, the identification function uses only the "low order" 64 bits (the IAD). 2.1. Unicast Addresses The SIPP unicast address or address sequence is contiguous bit-wise maskable, similar to IP addresses under CIDR [3]. The use of the optional Routing Header mechanism as the means of hierarchically extending SIPP addresses puts some constraints on the assignment and use of SIPP unicast addresses. First, since the Routing Header mechanism only allows a route to examine 64 bits at a time, a single "hierarchy element" from a SIPP hierarchical unicast address sequence cannot straddle a 64-bit boun- dary. Second, when using a 128-bit address sequence, both the low and high order 64 bits must individually be globally unique. (If the address sequence is greater than 128 bits, the middle 64-bit addresses may not have to be globally unique. In the event that SIPP address sequences grow beyond 128 bits, this possibility can be considered.) Third, routing must be configured such that, once a given 64-bit seg- ment of an address sequence is examined by a router for the purpose of forwarding a packet, previous (higher order) 64-bit addresses can- not subsequently be used as part of the forwarding decision. In other words, once the Routing Header is advanced to a certain 64-bit address, previous addresses cannot be examined. This places a minor constraint on routing's ability to selectively "look into" other parts of the hierarchy. SIP WG, Expires April 1, 1994 [Page 3] draft-ietf-sip-overview-00.txt October 1993 2.1.1. Unicast Address Assignment There are several forms of unicast address assignment in SIPP, including the global hierarchical unicast address, the cluster address, and the local-use address. The global unicast address is initially assigned as follows: |1| n bits | m bits | p bits | 63-n-m-p| +-+-------------------+---------------------+-----------+---------+ |C| provider ID | subscriber ID | subnet ID | node ID | +-+-------------------+---------------------+-----------+---------+ The first bit is the IP compatibility bit, or C-bit [6]. It indi- cates if the node represented by the address is IP-only or SIPP [8]. SIPP addresses are provider-oriented. That is, the high-order part of the address is assigned to providers, which then assign portions of the address space to subscribers, etc. This is similar to assign- ment of IP addresses under the CIDR scheme [3]. The provider ID numbers are assigned in such a way that an additional layer of hierarchy can be added above or below the provider ID layer. The node ID corresponds to IP's host number. Appendix A gives more details of the proposed approach to SIPP global unicast address assignment. 2.1.2. Cluster Addresses Cluster addresses are a special form of unicast address that allows a packet to be sent to one of multiple destinations (this type of delivery service is sometimes called anycast). Cluster addresses are of the form <prefix><zero>. Cluster addresses allow a packet to be sent to the "nearest" node (according to unicast routing's notion of nearest) of a group of nodes. The purpose of a cluster address is to be able to route a packet to one of a group of nodes characterized by sharing a certain prefix in the unicast global hierarchical address space. When the packet is being sent from "outside" the group of nodes (that is, being transmitted by a node that has no prefix in common with the cluster address), the resulting behaviour is that the packet is accepted by the first router whose own address prefix matches the prefix in the cluster address. When the packet is being sent from "within" the group of nodes (that is, being transmitted by a node whose own address prefix matches that of the cluster address), the resulting behaviour is that the packet is transmitted up the hierar- chy until it reaches a router that is acting "at the hierarchy level" of the prefix. SIP WG, Expires April 1, 1994 [Page 4] draft-ietf-sip-overview-00.txt October 1993 The SIPP routing and addressing specification will contain a precise and general definition of which nodes get assigned which cluster addresses. However, in the context of the initial format of SIPP hierarchical unicast address, the following cluster addresses are defined: Provider.0 Routers that comprise the provider's network (that is, not comprising subscriber networks attached to the provider) identi- fied by the Provider ID are assigned these cluster addresses. Provider.Subscriber.0 Routers whose addresses match with Provider.Subscriber, and that share a link with routers that have cluster address Provider.0 are assigned these cluster addresses. Provider.Subscriber.Subnet.0 Routers whose addresses match with Provider.Subscriber.Subnet, and that share a link with routers that have cluster address Provider.Subscriber.0 are assigned these cluster addresses. Packets with address Provider.0 will be accepted by the first router belonging to the indicated provider. This cluster address is used for provider selection and for forming provider-level policy routes. Packets with address Provider.Subscriber.Subnet.0 will be accepted by the first router in the indicated subnet. This cluster address is useful for auto-configuration and for mobile hosts where the scope of mobility is the subnet. If the scope of mobility is the subscriber network, then the cluster address Provider.Subscriber.0 can be used. The routing and addressing specification will describe how a host learns the various cluster addresses. 2.1.3. Local-Use Address A SIPP node can form a SIPP address from its own link address (for instance, its Ethernet address). This address is only guaranteed to be unique on the local link (from which the link address was derived). The link address can be used for local communication in a site, for instance for networks that are not connected to the inter- net, or temporarily for auto-configuration purposes. Local-Use Addresses have the following format: SIP WG, Expires April 1, 1994 [Page 5] draft-ietf-sip-overview-00.txt October 1993 | 8 bits | 8 bits | 48 bits | +--------+---------+---------------------------------------------+ |01111101|subnet ID| link address | +--------+---------+---------------------------------------------+ If the link address is less than 48 bits, then it is positioned at the low-order portion of the link address field and padded with zeros. If the subnet ID is unknown (for instance, because there is no router on the subnet), then the subnet ID is set to all zeros. 2.2. Other Address Formats The other address formats described in [8] (Multicast, Unspecified, Loopback, Reserved Multicast, All Nodes, All Hosts, and All Routers Addresses) are as specified in [8]. 3. ADDRESS SEQUENCE HANDLING BY NODES For address sequences to be an effective means of extending SIPP addresses or enriching SIPP routing semantics for use in provider selection, mobility, auto-readdressing, etc., nodes must be able to manipulate address sequences appropriately. A node must be able to recognize that its own addresses and other nodes' addresses may be represented as address sequences, for instance in transmitted and received packets and in DNS. A node must also be able to reverse address sequences for sending return packets. 3.1. Address Sequence Notation The SIPP mechanism for encoding address sequences is the optional Routing Header. With this mechanism, the active address of the optional Routing Header is in the destination address field of the SIPP header, and the remaining addresses in the address sequence (those that were previously active and those that will be active) are in the Routing Header. Thus, the fields of the Routing Header rotate through the destination address field as each becomes active. Notated literally, the mechanism would look like this: source address dest address Routing Header -------------- ------------ ------------ initial S A >B D next S B A >D final S D A B > This shows a packet from S, routed through A and B on its way to D. The '>' symbol indicates which field is next in the Routing Header SIP WG, Expires April 1, 1994 [Page 6] draft-ietf-sip-overview-00.txt October 1993 (i.e., the field pointed to by the Next Addr field of the Routing Header). While this notation accurately depicts what happens in the packet header, it is unwieldy, so the following equivalent notation is used instead: initial S,*A, B, D next S, A,*B, D final S, A, B,*D In this notation, the first element is in the source address field of the SIPP header. The '*' denotes the active element of the Routing Header, which is in the destination address field. The remaining elements are in the Routing Header, with the Next Addr field pointing to the element after the active one. This notation is easier to read, and not incidentally very similar to the Pip notation, thus illustrating that the original SIP Source Routing Header is semanti- cally similar to the Pip FTIF Chain. 3.2. Node Formation of Address Sequences This section describes a simple set of rules for the handling of address sequences. These rules allow nodes to form and transmit SIPP packets with traditional IP address semantics. More importantly, they allow nodes to receive and "reverse" SIPP packets with advanced routing and addressing semantics, such as policy routing. Thus nodes that do not understand advanced routing semantics can still operate appropriately when receiving packets from a node that does. Every node has a set of address sequences that it considers its own. These address sequences are a series of 64-bit addresses of the form <Si, Si-1, Si-2, ..., S0>, where S0 is the low-order address and also the IAD, and Si is the high-order address. Note that the terms low- order and high-order do not necessarily indicate that the high-order terms are hierarchically above the low-order terms. Rather, the implication is that the high-order terms must come first in an address sequence. [ Note that, for the purpose of allowing simple implementations, an address sequence of three addresses is considered sufficient to encode a node's source address for any reasonable forseeable requirement. ] An address sequence of a node constitutes the sum total of informa- tion needed in the packet header to route the packet to that node. Only the low-order address is required to identify the node. Some of a node's address sequences are source-capable and others are not. A source-capable address sequence is one that can validly be used as a "source address" in a transmitted packet. For instance, unicast SIP WG, Expires April 1, 1994 [Page 7] draft-ietf-sip-overview-00.txt October 1993 address sequences are source-capable and multicast address sequences are not, though both can be considered by the node to be its own address sequences. A route sequence may contain a number of components, such as a source address sequence, a destination address sequence, a policy route, a mobile host base station, or a multicast tree core address. From the perspective of a "simple" node, however, a route sequence contains only two parts, the source address sequence and the destination address sequence: <S0, S1, ..., Si, Dj, Dj-1, ..., D0> For a transmitted packet, the source address sequence is one of the node's own source-capable address sequences, and the destination address sequence is everything else. For a received packet, the des- tination address sequence is (or at least should be) any of the node's own address sequences, and the source address sequence is everything else. In an address sequence, the addresses of the source address sequence are ordered with the "low order" parts first, while the addresses of the destination address sequence are ordered in the opposite direc- tion, with the "high-order" parts first. Thus the first and last addresses are always the identifying addresses--the "low order" parts of the source and destination address sequences. In the common case with a single-component source and destination address, the complete route sequence simply has the form: <S0, D0>. Such packets contain no Routing Header. When a node has an "association" with another node (that is, a tran- sport connection or an application "connection" running over UDP), it must maintain the following information with respect to the correspondent node (the node with which it has the association): 1. The source and destination IADs for the entire association. 2. The source and destination address sequences currently in use. The low-order parts of the source and destination address sequences must match the IADs. When a node initiates an association, it will normally learn the des- tination address sequence through DNS or from local means (for instance, the user typing it in). It extracts the destination IAD for the association from the low-order part of the destination address sequence. It chooses from among its source-capable address SIP WG, Expires April 1, 1994 [Page 8] draft-ietf-sip-overview-00.txt October 1993 sequences for the source address sequence, and forms the header as indicated above. When a node is not the initiator of an association, it must extract the appropriate information from the received packet. A node can isolate its own address sequence from the received route sequence by matching the tail of the route sequence against its own address sequences. (Note that the multicast groups that the node belongs to are included in its list of address sequences for this isolation pro- cess.) Once the node isolates its own address sequence from the route sequence, what remains is the address sequence of the correspondent node. Thus, to return a received packet to the correspondent node, the node: 1. strips off and stores its own address sequence from the tail of the route sequence of the received packet, 2. reverses the order of the remaining elements of the route sequence, and places them on the tail of the route sequence of the returned packet, 3. prepends a valid source-capable address sequence to the route sequence, and 4. sets the active address (that is, the address to which the Next Addr field of the Routing Header points) to be the first address of the destination address sequence. If the node's own address sequence in the received packet is source- capable, then the transmitted (source) IAD must match that of the received (destination) IAD, and the transmitted address sequence should match that of the received address sequence. Every node must implement these reversal rules. Even if a node has no notion of, say, provider selection, it will successfully return packets to a node that does if it implements these rules. 3.3. Application Handling of SIPP Addresses The exact nature of the interface between the SIPP layer and higher layer protocols is still an open issue. At a minimum, an application interface that requires only the source and destination IAD must exist. This allows for a simple interface, but limits the control that the application has over routing. It should also be possible for an application to control the complete SIP WG, Expires April 1, 1994 [Page 9] draft-ietf-sip-overview-00.txt October 1993 route sequence if desired. The details of such an interface are under study. 4. ROUTING ALGORITHMS Initially, SIPP routing algorithms will be virtually identical to those used with the CIDR version of IP, except that the address used will be 64 bits rather than 32. Over the near term, cluster addresses can be configured into routers along with their native addresses, and advertised in the normal way. Eventually it would be desirable to have routers automatically determine their own cluster addresses. If it ever becomes necessary to extend SIPP addresses beyond 64 bits, then the routing algorithms can be modified if necessary to reflect that change. (Note that it is not clear that routing algorithms would have to be modified for this.) 5. UNICAST EXAMPLES In this section, we give several typical unicast examples that demon- strate the use of the Routing Header mechanism for provider selection and address extension. Later sections give typical examples for mobility, multicast, and auto-configuration. A forthcoming full specification of SIPP routing and addressing will describe the use of the Routing Header mechanism more thoroughly. The examples assume the following topology. Domain D contains node H. Domain E contains node I. Domain D is attached to providers P and Q. Domain E is attached to providers Q and R. 5.1. Simple (Non-Extended) Addresses Assume that the addresses of node H are P.D.H and Q.D.H, and the addresses of node I are Q.E.I and R.E.I, where the notation "a.b.c" represents a 64-bit SIPP address. (Note that the 'D' of P.D.H and Q.D.H are subscriber numbers assigned by P and Q respectively, and are therefore in general not the same value.) H initiates an associa- tion with I by querying DNS and learning the two addresses for I. Assume that H chooses Q.E.I, since it has the best "match" with its own addresses. H forms the following packet: Route sequence at sender H: Q.D.H, *Q.E.I I receives this packet, reverses the (in this case simple) route sequence, and returns: Reversed route sequence at receiver I: Q.E.I, *Q.D.H SIP WG, Expires April 1, 1994 [Page 10] draft-ietf-sip-overview-00.txt October 1993 5.2. Simple Addresses with Provider Selection The previous example is in fact a form of provider selection, but it is simple in that both ends have the same provider, so nothing expli- cit has to be done. Assume in this case, however, that H wishes to send its packet through provider P. Since I is not attached to pro- vider P, H must explicitly indicate that it wants its packet to go through provider P, and therefore forms the following packet: Route sequence at sender H: P.D.H, *P.0, Q.E.I The active element of the route sequence is the cluster address of provider P. This causes routers in domain D to route the packet to provider P. When the first router in provider P receives this packet, it recognizes the packet as being for "itself", and advances the Routing Header, producing: Advanced route sequence at provider P router: P.D.H, P.0, *Q.E.I which causes the packet to be routed to I. Upon receiving this packet, I uses the reversing rules stated above, producing the fol- lowing packet: Reversed route sequence at receiver I: Q.E.I, *P.0, P.D.H This packet has a couple of noteworthy characteristics. First, the packet may exit domain E via either provider Q or R, depending on what routing considers the best path to provider P. Second, the P.0 element is redundant, since the destination address P.D.H will also cause the packet to be routed to P. However, without knowing the provider mask of P, I has know way of knowing that P.0 is redundant with P.D.H, and so includes both elements. In the future, it may be possible for I to learn H's cluster address and optimize the header accordingly. To continue this example, assume that I does care which exit provider is used to reach H, and further that I chooses provider Q. In this case, I would insert the following "policy route" (actually, one address) to force the packet to go through Q outgoing: Alternative reversed route sequence: Q.E.I, *Q.0, P.0, P.D.H Note that this example describes a node that is more sophisticated than the simple one described previously. In particular, the node in this example understands three components of the source route (the source and destination addresses and a provider) rather than just two (the source and destination addresses). The node further understands that when it inserts the provider selector in the route sequence, it SIP WG, Expires April 1, 1994 [Page 11] draft-ietf-sip-overview-00.txt October 1993 sets the active element to be that of the provider selector on transmitted packets. 5.3. Extended Address (Address Sequence) Now assume that at some point 64 bits become inadequate and addresses are extended to an address sequence of two 64-bit addresses. In this case, H's address sequences are P.D:S.H and Q.D:S.H, where the colon ':' indicates a 64-bit boundary, and S represents a subnet inside domain D. I's address sequences are Q.E:S.I and R.E:S.I. For H to send a packet to I, it could form: Route sequence at sender H: S.H, Q.D, *Q.E, S.I The active element Q.E would cause the packet to be routed to domain E, where the Routing Header would be advanced to: Advanced route sequence at router in Domain E: S.H, Q.D, Q.E, *S.I and delivered to I. The above reversing rules executed by I would produce: Reversed route sequence at receiver I: S.I, Q.E, *Q.D, S.H thus returning the packet to I. 6. MULTICASTING IN SIPP This section describes how traditional multicast [5] works using SIPP route sequences. As with unicast, SIPP multicast address sequences are described using a series of 64-bit address elements. Thus, the node's notion of multicast addressing is extended such that a "multi- cast address" is seen as an address sequence rather than a single multicast address as is the case with IP. The final element of the multicast address sequence is the group ID. When a node joins a multicast group, it considers the multicast address sequence to be one of its own address sequences for the sake of packet reception and reversal. The multicast address sequence is not source-capable. In traditional multicast (also known as Deering multicast or source- based multicast), a packet from a sender to a multicast group is sent on the shortest-path delivery tree (rooted at the sender) to members SIP WG, Expires April 1, 1994 [Page 12] draft-ietf-sip-overview-00.txt October 1993 of the group. The traditional SIPP multicast address sequence con- tains only one address--the group ID. This section describes the Routing Header that is formed by the sender, the reversed Routing Header formed by the receiver and the necessary extensions to the multicast forwarding algorithm. 6.0.1. Example Assume the same scenario as described above (with nodes H and I), further assuming that H and I have extended addresses as described above. (We do an extended address example here because the simple address example is the same as with current IP.) Assume further that H is transmitting a traditional multicast with multicast address M, and that I is a member of group M. H forms the following header: Route sequence at sender H: S.H, Q.D, *M The route sequence is received unchanged at each of the receivers. If I wishes to respond unicast to H, it executes the reversing rules described above in the following way. First, it isolates its own address from the route sequence. Since this is multicast, and since I is a member of the multicast group M, I considers M to be one of its "own" addresses, and strips it. Reversing what remains produces <Q.D, P.H>. Since a multicast address cannot be used as a source address, I knows to prepend its own unicast address sequence to the route sequence, producing: Reversed route sequence at receiver I: S.I, Q.E, *Q.D, S.H 6.0.2. Multicast Forwarding Extensions With traditional multicast, each router's next hops are dependent both on the multicast group address and the sender address. When the sender's address is an address sequence next hop determination is potentially influenced by all of the addresses in the sequence. In the header formed by the sender, the SIPP Routing Header part con- tains all but the low-order address. Therefore, each multicast router will need to parse SIPP options for every packet containing a multicast destination address. For instance, in the above example, the routers would need to look at the destination address to deter- mine that it is multicast, then look in the Routing Header at "Q.D", then if necessary (for instance, because the packet is still inside domain D) look at "S.H" in the source address field. While this represents additional overhead, routers will not need to SIP WG, Expires April 1, 1994 [Page 13] draft-ietf-sip-overview-00.txt October 1993 incur this "peek-behind" overhead until 64-bit addresses are insuffi- cient for global routability of Internet nodes. 7. MOBILITY IN SIPP This section shows how SIPP source routing and SIPP route sequences might be used for mobile communication. Note that the Mobile IP group of IETF is deliberating on various solutions for mobility, and may choose a different approach than the one outlined here. At the same time, more approaches are possible with SIPP than with IP, so the Mobile IP group may choose a different solution for use with SIPP. First, we introduce some terminology. Mobile Host (MH) A node that is able to maintain its network connections even after being physically moved. Correspondent Host (CH) A node that has a network connection open to an MH. A CH may itself be mobile. Base Station (BS) The SIPP router to which the MH is attached after it moves. Home Station (HS) A SIPP node that is aware of the MH's current location. Each MH has a preconfigured home station. 7.1. Mobility Example Assume that H is an MH and that I is the CH, both with the (extended) address sequences from above. Initially, a packet from the CH to the MH carries the following route sequence as in the above example: Route sequence from CH to MH: S.I, Q.E, *Q.D, S.H Now suppose the MH moves to the vicinity of a BS with an address D.d. MH discovers D.d through SIPP "I-Am-Here" advertisements. These are multicast by the BS to the SIPP All Nodes address (similar to an IS hello advertisement in ES-IS). MHs also periodically multicast SIPP "I-Am-Here" advertisements to the SIPP All Routers multicast address (similar to the ES hello advertisement in ES-IS). This latter adver- tisement contains the MH's identifying address. Through a mechanism beyond the scope of this document, the MH informs the HS of its new base station. Packets carrying the old route sequence from the CH are intercepted by the HS. The HS tunnels them SIP WG, Expires April 1, 1994 [Page 14] draft-ietf-sip-overview-00.txt October 1993 to the BS, which forwards it to the MH. After the MH has discovered D.d, all subsequent packets to the CH carry the following route sequence: Route sequence from MH to CH after move: S.H, D.d, *Q.E, S.I It is sufficient to include only MH's identifying address in the route sequence; we assume that the BS is within I's IADs (S.I) rout- ing scope. When the CH reverses the incoming route sequence from the MH, it created the following route sequence: Reversed route sequence from CH to MH after move: S.I, Q.E, *D.d, S.H This causes packet to the MH to be routed through the BS at D.d, pro- ducing the desired behavior. 8. HOST AUTO-CONFIGURATION This section describes how a host constructs a temporary IAD when it boots and uses that to contact DNS or some configuration server to obtain host configuration information. We are interested in the four scenarios comprised of the combinations whereby 1) either a router is or is not on the host's local link, and 2) either the host can or cannot contact a configuration server. When a host boots up, it assigns itself a temporary local-use IAD formed from its link address. This IAD is routable only within the link on which the host is located. The host then sends out a small number of SIPP "Where-Are-You" soli- citations with the local-use IAD as the source address. If it receives no advertisements, the host assumes that there is no router on the link and uses the temporary IAD to communicate with other nodes on the link. If, using this IAD, the host is able to contact a configuration server on the link, then it may obtain a different, possibly global, address at this time. Once it hears a router advertisement, a host can use one of the advertised prefixes to form an address with greater routing scope. This address can be used to contact the configuration server. (The address of the configuration server could be a well-known multicast address.) If any of the prefixes advertised by the router is small enough to accommodate the host's link address (e.g., in the case of a multi-link domain not connected to the Internet), the host can con- catenate that prefix with its link address to form its address. Oth- erwise, the host can assign itself the address sequence <C, T>, where SIP WG, Expires April 1, 1994 [Page 15] draft-ietf-sip-overview-00.txt October 1993 T is the host's local-use IAD, and C is the cluster address of the subnet learned from the router advertisement. If a configuration server responds with a new address, the host uses that address. Otherwise, the host continues to use the previous address to communicate with other nodes (either in its domain or glo- bally). Note that the design of a configuration server is an open issue. References [1] S. Deering, "Simple Internet Protocol (SIP) Specification", Inter- net Draft, work in progress. [2] P. Francis, "Pip Near-term Architecture", Internet Draft, work in progress. [3] V. Fuller, T. Li, K. Varadhan, J. Yu, "Supernetting: an Address Assignment and Aggregation Strategy", RFC 1338. [4] P. Tsuchiya, "On the Assignment of Subnet Numbers", RFC 1219. [5] S. Deering, "Host Extensions for IP multicasting", RFC 1112. [6] R. Gilligan et al, "SIPP Transition Mechinisms", Internet Draft, work in progress. [7] P. Francis, "On the Assignment of Provider Rooted Addresses", Internet Draft, work in progress. [8] S. Deering, "Simple Internet Protocol Plus (SIPP) Specification", Internet Draft, work in progress. [9] R. Colellea, E. Gardner, R. Callon, "Guidelines for OSI NSAP Allo- cation in the Internet", RFC1237. SIP WG, Expires April 1, 1994 [Page 16] draft-ietf-sip-overview-00.txt October 1993 APPENDIX A: PROPOSED UNICAST GLOBAL SIPP ADDRESS ASSIGNMENT This appendix proposes an initial assignment scheme for SIPP global hierarchical unicast addresses that has the following characteris- tics: 1. it accommodates existing IP addresses, 2. it is an extension of the CIDR address assignment scheme, 3. it leaves address space open for several avenues of future growth. The initial assignment scheme for SIPP unicast addresses is provider-based, as follows: |1| n bits | m bits | p bits | 63-n-m-p| +-+-------------------+---------------------+-----------+---------+ |C| provider ID | subscriber ID | subnet ID | node ID | +-+-------------------+---------------------+-----------+---------+ | | | corresponds to current IP address | C-bit The left-most bit is the IPv4 compatibility flag [6], known as the C-bit. Both SIPP and IPv4 hosts can be assigned SIPP addresses in the SIPP unicast address space. Even though IPv4 hosts may be listed in the DNS with 64-bit SIPP addresses, they only "know" the low-order 32-bit part of their address. The C-bit is used by SIPP nodes to differentiate SIPP systems from IPv4 systems. SIPP systems are always assigned addresses with the C-bit set to 0. IPv4 systems are always given addresses with the C-bit set to 1. Provider Assignments Initially, the provider ID will be 31 bits in length. The provider mask is 32 bits in length (covering the provider ID and the C-bit). Provider IDs initially have the following format: | 8 bits | 24 bits | +--------+-----------------------+ |C0000000| provider ID, assigned | | | "from the left" [4] | +--------+-----------------------+ SIP WG, Expires April 1, 1994 [Page 17] draft-ietf-sip-overview-00.txt October 1993 The leftmost 7 bits of the provider ID (not including the C-bit) are assigned as 0. The subsequent 24 bits are assigned values according to the technique of assigning IP subnet numbers outlined in RFC 1219 [4]. That is, the "1" bits of the values are filled in from left- to-right rather than from right-to-left. This style of assignment reserves 0's on the right side of the provider ID, thus allowing the mask of a given provider to shrink in the future, if it is found that the provider needs more bits, for instance to identify its sub- scribers. For example, initial provider ID assignment would proceed as follows: first provider: C0000000 10000000 00000000 00000000 second provider: C0000000 01000000 00000000 00000000 third provider: C0000000 11000000 00000000 00000000 fourth provider: C0000000 00100000 00000000 00000000 fifth provider: C0000000 10100000 00000000 00000000 .... tenth provider: C0000000 01010000 00000000 00000000 This initial assignment of the provider ID space (zeros to both the left and right of the assigned bits) allows for several avenues of growth. For instance, if internet growth results in a small number of very large providers, then the masks of the providers can be shrunk, thus giving each provider more space, which could be used to add another level of hierarchy within the provider. If providers grew so large that they required even more space, they could be allocated codes in the most significant byte of the provider ID space. The reserved space in the most significant byte could also be used for different kinds of number assignments, such as geographical or organizational, if that becomes desirable in the future. (Strictly speaking it wouldn't be necessary for such different number assign- ments to have their own contiguous number spaces. For instance, the geographical codes could come from a portion of the provider space. However, having separate contiguous number spaces for different types of addresses simplifies address administration within each space.) If internet growth results in a large number of small providers, then it might be necessary for the zero bits in the most significant byte to be used as an additional layer of hierarchy above the provider level. Assignment of Lower 32 Bits The lower 32-bits of the SIPP address is initially nothing more than SIP WG, Expires April 1, 1994 [Page 18] draft-ietf-sip-overview-00.txt October 1993 the current IP address. After the IP address space expires (is no longer globally unique), then the lower 32 bits of the SIPP address will no longer by itself be globally unique, and will be assigned by the addressing authority identified by the higher 32 bits of the SIPP address (rather than being assigned by the current IP top-level address assignment authority). IP addresses currently exist under two formats, class-based (pre- CIDR) and class-less (CIDR) [3]. Pre-CIDR assignments have the fol- lowing format: | m bits | p bits | 32-m-p | +--------------+---------+--------+ | network | subnet | host | +--------------+---------+--------+ The IP network number corresponds to the SIPP subscriber ID. The SIPP subnet ID and node ID correspond to the IP subnet and host numbers respectively. The network number is globally unique among network numbers. Thus, providers have no control over the assignment of subscriber IDs derived from pre-CIDR IP addresses. CIDR assignments have the following format: | n bits | m bits | p bits |32-n-m-p| +-------------+--------------+---------+--------+ | provider ID |subscriber ID | subnet | host | +-------------+--------------+---------+--------+ Under CIDR, providers have control of subscriber assignments. After IP addresses are no longer unique, providers will also have control over the top n bits of the "IP address" (the lower 32 bits). These bits can be used either to assign directly to more subscribers, or to create a level of hierarchy above the subscriber level, resulting in: |1| 31 bits | n bits | m bits | p bits |32-n-m-p| +-+-------------+----------------+--------------+---------+--------+ |C| provider ID |sub-provider ID |subscriber ID |subnet ID|node ID | +-+-------------+----------------+--------------+---------+--------+ As mentioned above, it will also be possible for the sub-provider ID to grow into the provider ID space, by shrinking the provider mask for the provider. In general, as the internet grows, the structure of the SIPP global address may evolve to accommodate the growth. In the extreme case, the SIPP global address can expand to greater than 64 bits. Note that the use of provider-based addresses results in multiple SIP WG, Expires April 1, 1994 [Page 19] draft-ietf-sip-overview-00.txt October 1993 address prefixes for subscriber domains that are attached to multiple providers [7]. While this has the advantage of giving nodes a pro- vider selection feature, it has the disadvantage of added complexity in nodes, DNS, and address administration. SIP WG, Expires April 1, 1994 [Page 20]